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ABSTRACT 

This  paper  discusses  Ada  microcomputer  compilers 
and  seeks  to  provide  information  to  aid  in 
successful  selection  of  compilers  for  Ada  software 
development.  Selection  of  Ada  compilers  is 
significantly  more  complicated  than  selecting 
compilers  for  older  programming  languages. 
Effective  requirements  analysis  and  selection  of 
Ada  compilers  will  have  a  large  bearin,,  on  how  well 
project  teams  are  able  to  develop  Ada  software 
products  and  how  effectively  the  products  will 
execute. 


After  an  i  n  r  o  d  u  c  t  i  o  n 
section  of  this  paper 


in  Section  1, 
describes  the 


the  second 
benefits  of 


using  microcomputers  to  develop  Ada  software. 


studies  are  provided  to  give  examp 
microcomputers  can  be  integrated  into 
production  environment. 


examples  of  how 
into  a  software 


Choosing  an  Ada  compiler  is  the  topic  of  the  third 
section.  Specific  criteria  are  highlighted  and 
references  are  provided  to  publications  which 
provide  more  detailed  selection  guidelines.  Section 
4  then  discusses  some  of  the  currently  available 
compilers. 

Some  of  tile  current  limitations  and  problems  of  Ada 
compilers  are  discussed  in  Section  5-  Topics  sui^h 
as  iricremerital  compilation,  distributed  library 
systems,  and  low  level  features  are  covered  so  tliat 
prospective  Ada  developers  are  aware  of  the  types 
of  things  that  they  should  look  for  in  future  Ada 
compilers . 

Section  6,  on  experiences  and  performance  issues, 
provides  information  on  many  of  the  most  commonly 
asked  questions.  The  information  presented  refers 
mainly  to  the  AlsyC0MP_O05  compiler  for  the  IBM  PC- 
AT  and  compatible  computers. 

The  final  section  deals  with  future  directions, 
addressing  i  s  .s  u  e  s  such  as  compilation  rates, 
o  p  t  i  in  i  a  t.  i  o  Ti ,  and  compiler  environment  integration. 
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INTRODUCT [OH 


1.1.  'I’lll';  AOA  KV  A  I.IIA'I’  1  ON  TAOK 

.'1  .  ;!  .'1  p  e  1'  O  :i  ('  I  U  ;l  ■’  r  i  »)  w  li  i  .•  h  <•  ii  k  .-i  t  ■'  h  c’  I  p  p  I  i-  ii  !  -i  \  .1  -i 

developers  gain  praotinal  insight  into  what  is  reviuired  to 
successfully  develop  Ada  software-  With  this  goal  in  mind,  Air 
Staff  tasked  the  Command  and  Control  Systems  Office  (CC30)  to 
evaluate  the  Ada  language  while  developing  real-time 
communications  software.  The  task  involves  writing  papers  on 
various  aspects  of  Ada  development  such  as  training,  Ada  design, 
environments  and  security  issues.  This  paper  discusses  select!  or; 
and  usage  of  microcomputer  compilers. 

CCS  3  chose  the  Standard  Automated  Remote  to  AUTODIN  (Autow't'ic 
Digital  Network)  Host  (SARAH)^  project  as  the  vehicle  has; ;  for 
the  Ada  evaluation.  SARAH  is  a  small  to  medium  .size  pro.jecV 
(approx.  40,000  lines  of  source  code)  which  will  function  a.s  s 
standard  intelligent  terminal  for  AJTODIN  users  and  will  be  used 
to  help  eliminate  punched  cards  and  paper  tape  as  a 
transmit/receive  medium.  The  development  environment  for  ARAH 
consi.'its  of  a  number  of  IDM  PC  AT  and  Zenith  Z150  microcomputers, 
.and  a  Digital  Equipment  Corporation  (DkJC)  VAX  11/780.  The  source 
code  produced  is  compiled  on  the  PC  Afs  using  Alsys  Ada  compilers 
and  the  object  code  Is  targeted  to  both  the  Z150  and  PC  AT,  "he 
VAX  was  intended  to  be  used  for  configuartion  management  support 
and  to  function  as  a  repository  for  reusable  Ada  code.  The  SARAH 
software  will  run  on  a  range  of  PC  XT,  PC  AT,  and  compatible 
microcomputers  under  the  ilSDOS  operating  system  (version  2.0  or 
higher)  . 


1.2.  BACKGROUND 

The  dra(tiatic  increase  in  the  power  of  microcomputers, 
particularly  personal  computers  such  as  the  IBM  PC  AT,  has  made 
it  possible  to  use  these  machines  as  effective  Ada  development 
workstations.  Ada  is  resource  intensive.  For  example,  the 
comjiilers  themselves  generally  con.sist  of  more  than  300,000  lines 
of  complex  .-source  code.  In  a  d  il  L  t  i  o  n  ,  h  e  c  a  u  .s  e  of  the  s  t  r  i  i' t 
i  ri  t  e  r  -  ra  u  U  u  1  e  i ;  h  <;  i :  k  i  n  g  ,  A  d  .a  compilers  do  not  currently  support 
program  overlays  and  so  applications  generally  require  a  large 
amount  of  memory.  But,  the  future  is  bright  for  Ada  in  terms  of 
machines  which  will  be  able  to  support  Ada  development.  .oystems 
are  now  beginning  to  appear  that  use  the  new  80306 
microprocessor.  These  processors  support  up  to  4  Gigabytes  of 
physical  memory  and  64  Terabytes  of  virtual  memory^.  Moreover, 
the  80336  executes  at  four  Million  Instructions  Per  Second 
(.mips),  and  this  equates  to  the  power  of  a  Digital  Equipment 
Corporation  VAX  11/780  minicomputer.  This  is  indeed  a  dramatic 
increase  in  power  over  the  older  Personal  Computers  (PCs).  For 
example,  the  IBM  PC  XT  executes  at  only  333,000  instructions  per 
second  and  is  generally  limited  to  640  Kilobytes  of  physical 
me  fn  o  ry  . 


The  flexibility,  power,  and  cost  of  PC  workstations  make  them 
good  candidates  for  Ada  development.  In  the  future,  these 
workstations  will  play  a  large  role  in  Ada  production 
environments.  3y  effective  networking,  together  with  a  sy.stem  of 
distributed  source  and  library  databases,  micros  can  dramatically 
improve  development  throughput.  Individual  workstations  can 
support  4  number  of  general  purpose  and  Ada  a  pe  c  i  f  L  c  p  r  o  i  u  ■■  t,  i  v  i  t  y 
t  u  >  I  I  a .  A  I  1  r  , ' .  ■  number  of  t  b  e  c  c  tools  already  (ixi.it  i  i  r  I '  i) 
environment.!  and  d  <i  m  and  i  .i  c  n  c  ()  n  r  aging  the  development  o  C  m  .a  n  y 
more.  Ultimately,  these  tools  will  be  i  n  t  e  g  r  .a  t  e  d  i  n  t  ij  a  very 
powerful  Ada  development  environment  toget'ner  with  the  compiler. 

As  more  micro  compilers  become  available,  compiler  requirements 
analyst. s  and  selection  will  become  an  important  .step  in  the 
procurement  and  development  processes.  tn  addition  to  ensuring 
that  an  Ada  compiler  can  produce  good  quality  code  and  _'.;r'>le 
programs  quickly,  the  prospective  user  must  have  some  knowledge 
of  the  compiler's  targeting  capabilities,  how  well  the  compiler 
will  integrate  into  the  developme.at  environment,  and  the 
effectiveness  of  the  tasking  model  implementation.  To  assess 
quality  and  performance,  benchmarking  and  benchmark  reports  are 
an  important  oart  of  requirements  analysis  and  selection, 
■'.'ffective  requirements  analysis  and  selection  of  an  Ada  comp-ler 
play  an  important  part  in  determining  the  success  of  Ada 
projects. 

1.3.  PURPOSE 

The  purpose  of  this  paper  is  to: 

0  Provide  information  on  the  benefits  of  using 

microcomputers  for  Ada  software  development. 

0  Discuss  important  considerations  for  choosing 

microcomputer  compilers. 

0  Provide  details  on  currently  available  microcomputer 
compilers. 

0  Highlight  some  of  the  limitations,  performance  issues, 

and  problems  that  have  been  experienced  with 
microcomputer  compilers. 

o  Provide  information  on  what  to  look  for  in  future 

c  om  [I  i  1  e  r  s  . 


1.4.  SCOPE  AND  CONSTRAINTS 

i'h’s  paper  d'  acusses  various  .aspects  of  mi  I'ro computer  compilers; 
iiowever,  mort’  emphasis  is  given  to  Personal  Computer  (PC) 
environments  such  as  the  IHl  PC  AT.  This  has  been  done  for  a 
number  of  reasons.  First,  the  SARAH  team  has  received  a  large 


number  of  enquiriea  regarding  I’C  oompilera  and  ao  we  fe>’I  that  i 
discussion  of  this  type  would  seem  appropriate  at  this  time. 
Secondly,  there  is  a  large  range  of  computers,  loosely  termed 
microcomputers,  that  host  A.da  compilers.  A  discussion  of  each  of 
these  environments  and  their  respective  compilers  would  be  b<>y'’nd 
the  scope  of  t  h  l  s  type  of  paper.  headers  should  r  i'  f  e  r  to 
tiie  various  benchmarking  reports^  to  gain  additional 
information  on  these  systems.  Third,  we  see  the  PC  workstation 
as  an  important  tool  for  Ada  development  because  of  its  low  cost, 
flexibility,  and  versatility.  As  such  we  encourage  the  use  of 
PCs  arui  the  development  of  Ada  PC  tools. 
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2.  MICROCOHFUTliHS  KOR  ADA  DKVKLOPMKN'P 


'■licrocomputers  can  provide  cheap  and  versatile  Ada  workstations. 
Also,  an  Ada  development  environment  consisting  of  microcomputers 
is  more  survivable  than  an  environment  hosted  on  a  single 
machine.  For  example,  problems  with  one  workstation  will  not 
severely  affect  overall  production.  3ARAH  team  members  have 
found  tha^  working  with  individual  workstations  has  improved 
their  productivity  because  t ley  have  flexibility  in  choosing  and 
configuring  the  development  tools  for  their  particular  system  and 
they  have  the  full  power  of  the  compiler  wtien  it  is  needed. 

2.1.  ENHANCED  PRODUCTIVITY 

Development  productivity  can  be  enhanced  tfi  rough  the  tiai-  of 
workstation  compilers.  One  of  the  major  problems  with  current 
Ada  compilers  is  that  they  require  a  significant  amount  of 
computer  resources.  For  example,  on  a  vAXI 1/780,  current  Ada 
compilers  can  support  a  maximum  of  three  to  five  concurrent 
compilations  without  severe  performance  degradation  (i.e. 
compilation  rates  drop  below  usable  limits).  Some  compilers, 
for  example  the  SofTech  Ada  Language  System  (ALS),  severely 
iegradate  with  more  than  two  simultaneous  compilations.  3y  using 
a  network  of  microcomputers,  the  compilation  load  can  be  shared 
by  a  number  of  machines.  'ioreover,  if  the  project  team  expands, 
additional  machines  can  be  introduced  at  a  relatively  low  cost  so 
that  team  productivity  can  be  maintained. 


2.2.  TOOLS  FOR  PRODUCTIVITY 

The  PC  compiler  is  only  one  tool  which  can  enhance  software 
development:  the  PC  environment  will  support  many  general  and  ^da 
specific  tools  to  help  In  the  production  of  high  quality  Ada 
:i  oftware.  The  SARAH  team  uses  several  general  purpose  tools  to 
■I  i  <1  in  Ada  software  p  r  o  d  u  <•  t  i  o  n  •  For  example,  various  text 
editors  and  tools  such  as  Borland's  Sidekick  and  SuperKey  are 
used  to  support  development.  In  addition  to  the  general  purpose 
tools,  there  are  now  several  Ada  specific  tools  available  for 
PCs.  For  example,  Yinotech  Research,  INC.  markets  the  Xinotech 
Program  Composer  which  is  an  extremely  powerful  syntactical  Ada 
text  editor.  Other  tools  include:  an  on-line  Ada  encyclopedia 
from  Tacyon;  the  AdaGraph  design  and  development  system  from  The 
Analytic  Sciences  Corporation;  and  Sketcher,  an  interactive 
Graphical  Ada  software  design  tool  from  SYSCON.  The  PC  provides 
the  basis  for  an  extremely  powerful  Ada  development  environment 
but  the  full  benefits  will  not  be  realized  unless  the  tools  work 
together  in  an  integrated  manner. 


4 


OISTKllUITRD  DKVKF.OPMKMT  KN  V  I  KONMKN'Pij 


N  e  t  w  o  r  k  i.  n  {5  L  required  if  m  L  o  r  o  o  o  m  p  a  I  r  ;i  r  u  to  bo  u  o  o  q 
effectively  in  a  development  environment.  a  r  *  f  u  1  i  -  o  n  a  i  d  e  r  n  t  l  o  n 
m  u  o  t  be  I  V  e  n  to  how  m  I  e  r  o  e  nr"  u  o  e  d  for  n  o  f  t  w  n  r  e  d  i»  v  r>  I  o  j  m  i  >  u  '  . 
otherwise  o  e  r  I  o  u  s  ■■  o  n  f  1  u  r  .h  t  i  u  n  control  m  n  d  p  i-  o  d  u  -•  t  i  v  l  t  y 
problems  will  arise.  Ror  example,  without  a  e'.  work,  team  members 
are  more  inclined  to  maintain  their  own  versions  of  the  modules 
they  are  developing  rather  than  constantly  updating  a  central 
project  library.  To  use  micros  effectively,  a  distributed 
environment  which  maintains  a  distributed  source  data  base  and 
distributed  library  system  should  be  installed.  The  file  server 
should  host  configuration  management  tools  and  allow  for  target 
code  production  if  embedded  applications  are  being  developed. 

The  development  environment  used  by  Alsys  Inc.  of  Waltham  "lA 
provides  a  case  study  of  how  micros  can  be  used  for  Ada  software 
development.  Alsys  uses  a  scheme  where  each  engineer  on  the 
compiler  project  has  a  PC  AT  and  these  are  connecled  to  a  VAX 
1  1  /  7  b  0  via  (i  t  h  e  r  ti  H  t  .  The  network  has  an  e  f  f  e  c  t  i  v  e  i  a  l  a 
transmission  rate  of  about  one  megabyte  per  minute.  Tools  such 
as  the  VAX  DCC/Code  Management  System  (CMS)  provide  functions 
sucli  as  configuration  management.  The  VAX  also  provides  a 
repository  of  Ada  source  code.  The  network  cost  Alsys 
approximately  $6000  for  VAX  enhancements  and  $1000  for  each  PC. 
The  proliferation  of  networks  for  PCs  has  reduced  costs 
signi f lean t ly  and  as  prices  continue  to  fall,  the  total  cost  of 
installing  this  type  of  network  will  be  far  less  than  the  quoted 
figures. 

Another  source  of  information  on  using  micros  for  Ada  software 
production  is  the  Software  Engineering  Institute  (SEI).  The  SET 
will  provide  information  on  distributed  development  environments 
as  a  result  of  their  Showcase  Environment  project^.  Their  50. h1 
is  to  implement  a  software  development  environment  to  suppoi't  the 
construction  of  software  systems  co.isisting  of  up  to  one  railllo.i 
lines  of  source  code.  The  SEI  intends  to  exploit  the 
capabilities  of  workstations  with  high  resolution  graphics 
displays.  These  workstations  will  be  supported  by  local  area 
netwoi-ks-  The  results  of  the  work  being  done  by  the  SEI  on  the 
Showcase  Environment  could  prove  oener..^ial  fv..  i  ■nations  wio 

are  contemplating  installing  a  distributed  Ada  development 
environment. 

CeSO  attempted  to  implement  an  Ada  development  environment 
consisting  of  a  number  of  PCs  and  a  VAX  11/780:  however,  the 
result  was  not  particularly  successful.  One  of  the  major  reasons 
was  that  no  local  area  networking  facilities  were  available.  As 
such,  the  time  required  to  upload  and  download  data  was 
excessive.  In  addition,  the  communications  package  being  used 
was  not  particularly  friendly  and  so  team  members  were  reluctant 
to  use  the  system.  Another  problem  was  that  the  SofTech  Ada 
Language  oystem  (ALS)  was  to  provide  the  automated  configuration 
management  support  for  the  project.  The  tools  provided  by  the 
ALS,  were  good  in  concept,  but  some  were  unreliable  and  not 
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particularly  easy  to  use.  It'  PCs  are  to  be  used  in  an 
development  environment,  then  thought  needs  to  be  given 
networking  and  effective  tools  need  to  be  secured  to  aid 
source  code  management. 


Ada 
t  o 
i  n 
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5.  CHOOSING  A  NICKO  COHPll.KK 


An  e''.ctive  requirements  analysis  for  the  selection  of  m i c r '  Ado 
A  o  ,1  p  i  1  e  r  s  will  become  ever  more  important  as  t  li  -■  n  u  m  1  r  ,j 
tva liable  compilers  increases.  Ihis  section  discusses  selection 
criteria  for  Ada  compilers.  Ada  compilers  are  very  c imp  lex 

pieces  o  software  and  are  intended  to  be  used  in  an  Ala 
p  T-  )  j.- r  a  m  m  1  ng  Support  environment  (APSE).  As  sucri,  many  p  a  r  a  i:.  t  e  r  c, 
must  be  considered.  In  addition  to  a  a  i  (■  s  s  ;  n  g  compiler 
requirements,  prospective  users  must  assess  quality  anl 
effectiveness  for  Ada  software  production.  Several  metnji.a  'an 
be  used  t  )  a  s  s  '  i;  3  these  criteria.  E  o  r  example,  this  sect,; 
d  .  s  c  u  .1  3  e  s  the  use  >  ('  benchmarking,  be  n  c  h  in  a  r  k  teat  r  e  s  a  ;  t  s  ,  fi  'i  -i  1  a 

.1  e  X  p  e  r  i  e  11  o  o  ,  a  n  i  1  i  s  c  u  .s  s  i  o  n  s  with  users  to  a  i  i  in 

selection.  :!  e  v  e  r  a  I  other  important  c  o  n  a  i  d  e  r  a  t  i  n  s  o  n  a  . 
r  a  11  t  1  m  e  '  e  X  e  c  u  t  1  V  e  licenses  and  vendor  supplied  packages  .a  r  a  1  s  .) 
1  i  c,  c  a  s  3  e  d  .  Appropriate  selection  of  Ada  ■;  o  m  p  i  1  e  r  s  .  an 
important  step  for  successful  development  of  Ada  s  'ft  ware 
products. 

3.1.  SELECTION  CRITERIA 

I  he  selection  criteria  for  Ada  compilers  is  more  complex  tb-'t 
that  generally  applied  to  the  selection  of  compilers  for  ’.i.,- 
L  -1  n  g  1  a  r  e  s  .  Wallis  and  W  i  c  h  m  a  n  n  ^  indicate  that  "  . .  i  d  e  -i  1  I  y  .  a 

■  o  m  t'l  i  1  e  1-  I  'll  o  u  1  d  compile  the  Language  d  e  f  i  ri  e  q  in  the  1  .a  n  g  u  -i  ' 

s'  ind-irl,  produce  good  qu-ality  code,  n'orapile  programs  quickly  ana. 
give  good  diagnostics  when  needed.  These  are  indeed  requirements 
for  a  good  i'  0  m  pj  i  L  e  r  ,  be  it  L'  a  s  c  a  1  ,  Fortran,  or  Ada.  ^  u  t  ,  f  o  :• 
Ada,  several  other  criteria  also  need  to  be  considered.  For 
example,  one  also  needs  to  know  which  targets  are  supported,  haw 
well  the  compiler  fits  into  the  development  environment,  and  how 
effectively  the  compiler  supports  tasking  and  low  level  features. 

A  list  of  essential  parameters  for  compiler  selection  has  been 
generated  by  an  Ada-Surope  working  group^.  This  guide  is  wx-itten 
from  the  point  of  view  of  someone  wishing  to  know  something  about 
an  existing  compiler  and  indicates  what  information  may  be  needed 
from  the  compiler  supplier.  A  check  list  is  provided  for  each 
criteria  and  the  guide  is  very  easy  to  follow.  Anyone 
considering  the  selection  of  an  Ada  compiler  would  be  well 
advised  to  look  at  this  guide. 

An  important  criteria  for  t  h  t;  selection  of  an  A  a  compiler  i  : 
how  well  will  the  compiler  integrate  into  Mie  working 
environment'^  ihere  are  many  things  that  need  to  be  considered. 

For  example,  does  the  compiler  prod -ice  intermediate  pro--ru"' 
representation.s  (e.g.  DIANA  (Descriptive  Intermediate  Attribut'^ii 
Nutation  for  Ada)  code).  is  there  .a  human  readable  form  of  this 
•ode'’  'Will  other  tools  .such  as  debuggers  be  able  to  use  t  o  i  s 
r  e  p  r  e  :j  e  ri  t  a  t  i  o  n 'i’  Can  other  general  purpose  tools  be  invoked  wb.en 
the  lompiler  is  loaded 'f  The  SARAH  team  experienced  txie 
integration  problem  first  hand.  When  the  Alsys  compiler  (Version 
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I  j)  was  procured  for  the  Pd  '>^’3,  everyone  was  dismayed  hy  the 
fact  that  tools  such  as  Sidekick  and  S  u  }i  o  r  Key  would  not  run  when 
t!ie  compiler  whs  loaded.  "I'e.ain  members  had  been  using  these  t.)ol3 
jirevLously  and  found  that  they  signiflcaritly  linjjrovei  the 
effectiveness  of  the  workstations.  Thankfully  A  1  ys  whs  h  f  t  u  n  e 
to  u  r  needs  a  ti  d  when  Version  1  .  P  of  the  compiler  w  a  .■  released, 
we  were  once  again  able  to  use  our  favorite  tools.  The  priblems 

of  incompatibility  will  be  more  pronounced  when  more  Ada  specifc 

tools  are  released.  Sffective  integration  of  Ada  tools  for 
microcomputers  is  an  importa-it  consideration. 

Target  support  is  another  criteria  that  must  be  considered  when 
selecting  a  micro  Ada  compiler.  Por  example,  the  Alsys  compiler 
targets  to  the  PC  A?  and  PC  XT  (and  selected  compatible 

computers)  runiiing  under  the  MSDOS  operating  system.  The  CAofo 
compiler  is  also  hosted  on  the  PC  AT  but  it  will  not  ta'-get  code 

to  run  under  M3  DOS.  The  two  compilers  run  on  the  same  host  but 
are  completely  different  and  are  used  for  different  I’ea  so  ns:  the 
ilsys  produces  MSDOS  applications  software,  whereas  the  lASYS 
will  be  used  for  producing  embedded  software  applications,  far.' 
must  be  taken  to  select  the  right  compiler  for  the  job. 

■j  .  2  .  V  A  L  I  D  A  r  1  0  H 


Validation  does  not  ensure  quality!  This  is  perhaps  one  of  the 
most  important  things  to  remember  when  procuring  an  Ada  compiler. 
Validation  simply  ensures  that  the  compiler  conforms  to  the 
language  definition  and  is  only  a  small  part  the  overall  compiler 
specification^.  ■•Iven  though  a  compiler  is  validated,  it  may  have 


a'-’‘=>cceptable  compilation 
inefficient  code.  The  Ada 
if  the  compiler  conforms 


rates,  be  unreliable,  and  may  produce 
Validation  Office  (AVO)  checks  to  see 
to  the  language  standard'^  but  does  not 


attempt  to  provide  any  information  on  quality  or  effectiveness. 
Ar  such,  the  prospective  user  must  resort  to  other  methods,  such 


as  benchmarking,  to  ensure  that  the  compiler  will  indeed  meet 


requirements. 


3.3-  BENCHMARKING 

Benchmarking  plays  a  big  part  in  determining  the  quality  and 
effectiveness  of  compilers.  As  discussed,  validation  ensures 
tb-it  the  compiler  conforms  to  the  language  standard  but  says 
nothing  about  quality  or  efficiency.  Benchmarking  and  benchmark 
test  results  can  provide  comparative  data  that  can  be  used  to 
assess  the  performance  of  compilers. 


Copies  of  benchmark  test  results  are  now  becoming  available  and 
can  be  extremely  useful  for  compiler  selection.  A  big  benefit  of 
getting  benchmark  test  results  is  that  the  testing  is  generally 
done  in  conjunction  with  a  test  methodology  and  so  comparative 


studies  are  generally  more  accurate  than  if  the  tests  were 


applied  by  inexperienced  personnel.  The  3EI 
published  benchmarks  for  several  environments®. 


has  recently 
This  document 


also  outlines  the  methodology  that  was  used  for  the  tests. 


n 


4  o  p  t!  f  a  I  1  y  ,  t  h  H  S  iO  I  w 
reports.  Specifll 

.ssae.3  Workirif^  (Jroup 
These  results  will  be 


11  coatinue  to  produce  these  high  quality 
Interest  Group  on  /Ida  (ii'ilAda)  Performance 
is  also  compiling  benchmark  test,  r  e  u  1  t  s  . 
made  evai table  to  SIGAua  members. 


I'  ti  e  Ada  Compiler  K  v  ,■)  1  u  a  t  I  o  n  Capability  (  A  C  C  )  will  be  ,i  very 
effective  set  of  benchmarking  tools  for  determining  the  qunli  ty 
and  eff active ne.js  of  various  compilers.  The  prototype  AC.CC  became 
available  from  the  Ada  Validation  Facility  in  January  1 d86.  The 
benchmark  tests  were  collected  and  organized  into  this  prototype 
suite  by  the  Ada  Pi-ogramraing  Support  Environment  (APSE) 
Svilua‘'ion  and  Validation  (E<SV)  team.  To  get  a  copy  of  the 
prototype  teat  suite  a  request  can  be  submitted  to; 


The  Ada  Validation  Facility 
AD3/SI0L 

Wright  Patterson  AFB 
OH  45433-6503 


Tne  request  must  be  on  a  company  letterhead  and  shouli  be 
icccmpanled  by  a  C400  foot  magnetic  tape  (tape  format  information 
must  be  providel).  Additional  teats  and  an, a  ly.iis  tools  will  be 
available  in  the  ACEC  when  it  becomes  available. 

Benchmarking  gives  you  a  chance  to  get  "hands-on"  experience  with 
the  compiler  before  purchase.  This  is  important  since  with 
"hands-on"  the  user  interface  and  general  usability  criteria  can 
be  assessed.  Even  if  test  results  are  used  to  assess  whether  a 
compiler  will  meet  project  requirements,  organizations  should 
attempt  to  use  the  compiler  before  purchase.  The  benchmark- 
programs  can  be  used  for  gaining  this  "hands-on"  experience.  By 
using  the  compiler,  prospective  users  can  get  a  good  idea  of 
reliability,  the  quality  of  user  documentation,  and  general  ease 
of  use. 


3-4.  DISCUSSIONS  WITH  USERS 

One  of  the  best  ways  to  determine  how  well  a  particular  compiler 
performs  or  whether  it  is  suitable  for  your  needs  is  to  talk  to 
experienced  users.  The  SIGAda  meetings  provide  an  excellent 
forum  to  engage  in  these  discussions.  Three  national  SIGAda 
meetings  are  held  each  year  and  local  groups  generally  have 
regular  meetings.  Most  of  the  larger  vendors  also  support  users' 
groups  for  their  products.  Attendance  at  these  meetings  provides 
a  good  insight  into  the  quality  and  effectiveness  of  particular 
products.  For  more  information  on  SIGAda  meetings  conta'-t; 

Alla  Information  Clearinghouse 
^  i)  I  V)  (  I  ,>1  I  3.  ''’em,  C-  1  07  ) 

The  Pentagon 

Washington  D.C.  20301-3081 
Ph.  (703)  685-1477 
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currently  validated  compilers  and  other  Ada  related  i n fo r m a t  I  o n . 

3.5.  RUNTIME/EXECUTIVE  LICENSES 

rfhen  selecting  a  compiler  remember  to  check  the  license 
agreements  and  contracts  carefully.  Some  compiler  vendors  are 
charging  royalties  on  the  runtime  package.  Eor  example,  Alsys 
provides  10  free  executive  licenses  with  each  compiler.  This 
means  that  if  the  application  being  developed  will  be  used  on 
more  than  10  systems  or  if  the  software  is  to  be  sold  to  more 
than  10  people,  then  license  fees  must  be  paid  to  Alsys-  The 
fee;  vary  with  the  number  of  times  the  runtime  software  will  be 
used.  o  r  number",  between  11  n  n  d  1  O  O  O  Alsys  must  be  paid  .ji '  ■  i ) 
[’  e  r  ('  o  p  y  .  This  re  d  u  c  e  s  to  S  b  per  copy  for  n  u  ni  b  e  r  .s  r  "i  n  g  i  ii  g  C  r  ■ .  "ii 
1  1)1  t  h  r  )  n  g  h  10  0,000.  \  .s  mure  compiler  s  li  e  c  o  in  e  a  v  a  i  I  a  hie, 

organizations  woul'l  bo  well  advised  to  stay  clear  of  compilers 
that  have  this  type  of  licensing  scheme. 

3.6.  VENDOR  SUPPLIED  PACKAGES 

A  major  benefit  of  Ada  is  that  the  language  is  standardized  and 
stri-ctly  controlled  by  validation  and  is  not  tied  to  individual 
vendors  or  machines  But,  is  this  entirely  correct?  Several 
vendors  are  providing  additional  packages  that  aid  the  software 
developer  but  these  packages  take  the  form  of  an  Ada  pre-defined 
package  (i.e.  no  source  code  is  provided).  Alsys  provides  two 
such  packages:  'Unsig, ned'  and  'DOS'.  The  DOS  p-ickage  provides  .a 
number  of  functions  that  make  calls  to  the  M3D03  operating 
;y;tein.  fi’eatures  such  as  buffered  keyboard  input,  fil^ 
input/output,  and  absolute  disk  access  are  provided.  Without 
doubt,  these  features  are  necessary  in  many  applications  and  the 
llsys  package  can  save  development  time.  However,  since  source 
cotie  is  not  provided,  the  applications  software  cannot  be 
compiled  with  another  Ada  compiler  unless  a  DOS  package  similar 
to  the  Alsys  package  is  developed.  In  a  sense,  if  a  vendor's 
pre-defined  packages  are  used,  the  applications  developer  is 
tying  the  application  to  a  particular  compiler  vendor.  As 
stated  earlier  this  can  be  dangerous. 


4.  CURRENTLY  AVAILAULE  MICRO  COMPILERS 


'1'  h  «i  n  u  111  h  ri  r  of  v  a  L  i  il  i  t  h  d  Ada  i!  o  ni  p  I  I  o  r  a  la  i  n  ■ :  c  ,>i  i  i  n  g  at  a  r  .1  .<  I 
rate.  One  of  t  h  e  m  a  J  e  r  r  0  a  a  e  n  :i  for  t  li  e  r  a  p  i  d  i  ri  1  ■  f  e  a  a  e  i  a  t  m  a  1. 
Ada  compiler a  ire  easily  reheated  and  so  a  "bane”  compiler  can 
run  on  a  large  number  of  different  machines.  As  such,  many  of 
the  compilers  that  run  on  larger  machines  will  also  run  on 

micros.  This  section  discusses  some  of  the  currently  available 
compilers,  provides  references  for  obtaining  more  comprehensive 

and  up-to-date  lists  of  validated  compilers,  and  provides 
information  on  some  of  the  PC  compilers  currently  under 
development . 

4.1.  REHOSTING 

Since  most  Ada  compilers  are  themselves  written  in  Ada,  reho.-iting 
to  other  environments  has  not  been  as  difficult  as  has  been  the 
case  with  older  languages.  As  such,  many  of  the  compilers  that 
were  developed  on  larger  machines  have  been  rehosted  to 

microcomputers.  Kor  example,  several  compilers  and  environments 
have  been  rehosted  to  the  MicroVAX.  Some  of  the  compilers 

currently  available  for  the  MicroVAX  are  the  DSC  VAXAda,  the 
SofTech  ALS,  and  TELESOFT'a  TeleGEM.?.  Another  very  popular  mici'o 
based  workstation  is  the  Sun  Microsystem.  Organizations  sucii  as 
Tele  soft,  Verdix,  Alsys,  TeleLOGIC,  and  New  York  University  have 
rehosted  their  compilers  to  this  environment. 


4.2.  COMPILER  INFORMATION 

The  Ada  Information  Clearinghouse  (AdalC)  is  one  of  the  best 
sources  to  find  out  which  compilers  are  currently  validated  and 
which  vendors  have  indicated  their  intention  to  validate. 
Current  validation  lists  are  provided  in  each  copy  of  the  AdalC 
newsletter.  The  lists  provide  information  on  the  vendor  and 
compiler,  the  host  machine,  and  target  machines.  In  addition 
AdaiC  maintains  an  Ada  Language  Implementations  Matrix^  which 
shows  all  validated  compilers  as  well  as  compilers  that  are  under 
development  or  waitirig  validation. 


4.3.  PC  COMPILERS 

Til  ere  is  still  not  a  large  range  of  validated  compilers  f-r  PCs. 
One  of  the  major  problems  has  been  that  the  PC  environments  have 
not  been  powerful  enough  to  accommodate  an  Ada  compiler.  Eor 
example,  most  PC  systems  have  been  limited  to  64O  Kilobytes  of 
memory  and  execution  rates  have  typically  been  less  than  1  MIPS. 
The  IBM  PC  AT  now  provides  an  adequate  environment  to  support  Ada 
development,  and  future  machines,  based  on  the  80386 
microprocessor  or  equivalent,  will  allow  vendors  to  effectively 
rehost  their  compilers  or  develop  specific  PC  compilers.  Since 
PCs  are  cheap  and  provide  an  environment  that  has  become  an 


industry  standard,  PC  compilers  will  be  an  important  ind 
lucrative  market  for  vendors. 

Two  compilers  that  have  been  validated  on  the  IBM  PC  AT  and 
compatibles  are  the  Alsys  Al3yC0MP_003  and  the  OASYS  PC  Platform. 
These  products  are  very  different  in  concept.  The  Alsys  compiler 
runs  under  the  MSDOS  operating  system  and  directly  uses  the  PC 
hardware.  To  run  the  compiler,  the  PC  AT  memory  must  be  expanded 
to  4  Megabytes.  Alsys  markets  their  compiler  with  a  4  Megabyte 
memory  board.  Object  code  generated  by  the  Alsys  compiler  must 
run  under  MSDOS  and  can  use  the  protected  memory  mode  of  the 
80286  microprocessor  in  the  PC  AT.  Applications  are  therefore 
limited  only  to  the  maximum  memory  that  the  80286  can  support  (’6 
Megabytes).  Object  code  can  also  be  targeted  to  the  8088  based 
PC  XT  but  the  application  must  not  exceed  640  kilobytes. 

The  OASYS  PC  Platform  does  not  exclusively  use  the  PC  hardware 
for  operation.  To  use  the  OASYS  system,  a  processor  card  must  be 
Lost  a  lied  and  this  card  hosts  the  compiler.  The  platform  card 
contains  a  32  bit  NS32032  microprocessor  operating  at  12-5  Mega 
Hertz  and  up  to  16  Megabytes  of  memory.  As  such,  the  PC  itself 
is  only  used  as  an  input/output  processor  for  the  installed  board 
which  gains  control  of  the  entire  system.  Tne  compiler  that  is 
hosted  by  the  PC  platform  is  the  Verdix  Ada  Development  System 
(VADS)  and  runs  under  the  UNIX  V.2  operating  system.  A  major 
difference  between  the  Alsys  and  OASYS  compiler  is  that  the  OASYS 
does  not  target  to  the  MSDOS  environment  and  will  not  produce 
code  to  run  on  the  host  machine.  One  of  the  advantages  of  the 
OASYS  compiler  is  that  all  the  VADS  embedded  targets  will  be 
supported.  This  will  include  target  support  for  the  1750A, 
68000,  MS  3 2032,  and  a  range  of  Intel  processors.  In  summary, 
the  OASYS  system  does  not  currently  target  applications  to  run 
under  MSDOS  in  the  host  configuration  and  uses  a  separate 
processor  board  for  operation.  The  Alsys  compiler  is  a  true  PC 
AT  compiler  but  does  not  support  targets  other  than  the  PC  AT  and 
PC  XT;  applications  must  run  under  MSDOS. 

Other  organizations  tfiat  have  indicated  their  intention  to 
validate  on  PCs  are  ARTEK,  JANUS,  General  Transformations,  New 
York  University,  and  General  Systems  Many  organizations 
attempting  to  develop  low  cost  Ada  compilers  for  PCs  have  failed 
because  they  have  underestimated  the  complexity  of  the  language 
and  the  computer  resources  necessary  to  run  the  compilers.  For 
example,  the  Alsys  PC  AT  compilers  consists  of  approximately 
300,000  lines  of  source  code  and  requires  6,161  kilobytes  of  disk 
storage  to  load.  The  requirements  for  inter-module  checking, 
run-time  error  checking,  and  concurrent  processing  place  a  heavy 
burien  on  developers  and  host  architectures.  However,  continued 
compiler  research,  more  experience,  and  more  powerful  PCs  will 
result  in  many  more  Ada  compilers  for  PCs.  As  more  compilers 
become  available,  costs  should  also  decrease. 


5-  COKPILBH  LIMITATIONS  AND  PROBLEMS 


Many  of  the  limitations  and  problems  discussed  in  this  sectLon 
are  not  peculiar  to  micro  compilera.  Indeed,  the  problems  affect 
a  very  large  number  of  currently  available  Ada  compilers.  A 
discussion  of  problems  and  limitations  are  provided  in  this  paper 
to  increase  general  awareness  and  to  help  in  successful  compiler 
requirements  analysis  and  selection.  Some  of  the  limitations  and 
problems  discussed  in  this  section  are:  the  lack  of  incremental 
compilation,  the  need  for  integrated  PC  environments,  the  lack  of 
target  support,  the  need  for  distributed  library  systems,  and 
support  for  low  level  features. 

5.1.  INCREMENTAL  COMPILATION 

Incremental  compilation  allows  the  user  to  make  changes  to  a 
module  without  having  to  recompile  all  the  dependent  module;. 
The  lack  of  incremental  compilation  can  result  in  a  huge 
recompilation  overhead.  This  is  because  the  dependencies  built 
into  Ada  for  inter-module  consistency  checking  can  cause  even 
insignificant  changes  to  result  in  a  propagation  of 
recompilations.  Ada  compilers  need  to  support  interactive 
changes.  One  way  to  support  interactive  changes  without 
incurring  excessive  delays  is  to  incorporate  the  changes  in  some 
rich  data  object  such  as  a  DIANA  tree  which  preserves  syntactic 
and  semantic  information  rather  than  in  simple  ASCII  text  files. 

Of  th*)  compilers  currently  validated,  only  the  Rational  supports 
incremental  comp L  I  a t t on.  Hopefully,  as  the  s t a t e- o f - t he - p ra c t  i  c e 
for  Ada  compiler  design  improves,  necessary  features  such  as 
incremental  compilation  will  become  c oram o n - p 1  a c e  ,  even  on 
ra i c  roc ompu  t  e  rs . 

5.2.  INTEGRATED  ENVIRONMENTS  FOR  PCs 

The  lack  of  an  integrated  t  o  o  1  s  e  t  /  e  n  v  i  r  o  nme  n  t  is  a  serious 
limitation  to  the  Ada  developer.  A  great  deal  of  effort  has  been 
expended  in  defining  Ada  Programming  Support  Environments 
(APSE)^^  and  tool  interfaces  (Common  APSE  Interface  Set)^^  but 
the  recommendations  may  not  be  entirely  sufficient  for 
distributed  Ada  development  environments  consisting  of  a  large 
number  of  micros.  Indeed,  organizations  producing  Ada  tools  for 
PCs  (including  compiler  vendors)  are  paying  little  attention  to 
any  standard  tool  interfaces. 

A1  though  there  are  several  Ada  specific  tools  now  available  for 
the  PC  and  many  more  currently  under  development,  little  thouglit 
has  been  given  to  integration.  If  the  tools  are  to  be  truly 
effective  in  a  PC  environment,  then  they  must  be  integrated.  For 
example,  users  should  be  able  to  move  easily  between  the  editor, 
compiler  and  debug  facilities.  This  should  be  accomplished 
through  some  modern  user  interface  (perhaps  consisting  of  a 
system  of  icons  and  windows).  Also,  standard  interfaces  should 


be  provided  for  distributed  source  databases  and  compilation 
libraries.  Interfaces  for  local  area  network  communications 
should  also  be  well  defined  so  that  the  power  of  networking  can 
be  fully  realized.  Powerful  Ada  development  tools  for  PCs  are 
beginning  to  emerge;  however,  a  standard  method  of  integrating 
the  tools  is  yet  to  be  defined. 


5.3.  LIMITED  TARGETS 

The  Ada  software  industry  is  drastically  in  need  of  compilers 
which  target  to  a  range  of  embedded  computers.  The  Ada  language 
was  primarily  designed  to  support  the  development  of  software  for 
embedded  systems.  Yet,  to  date  there  are  very  few  compilers  that 
target  to  a  range  of  embedded  computers.  Microcomputers  such  as 
the  DEC  MicroVAX  support  a  number  of  products  that  will  target  to 
embedded  systems;  however,  the  range  is  extremely  limited.  For 
example,  until  recently,  if  an  embedded  application  was  required 
for  an  8086  based  embedded  system,  then  the  only  compiler  that 
could  be  used  for  development  was  the  ALS. 

If  a  PC  network  is  to  be  used  for  development  of  embedded 
applications  then  some  thought  must  be  given  to  how  the  targeting 
will  be  accomplished.  Compilers  such  as  the  one  produced  by 
Alsys  are  excellent  for  developing  source  code  and  general 
debugging,  but  do  not  target  to  a  range  of  embedded  systems.  To 
provide  the  target  code,  a  machine  must  be  selected  which  will 
ho  ."it  a  compiler  th.at  targets  to  the  embedded  system  under 
develoiiraent.  l''or  example,  the  Navy  stand, a  rd  embedded 
arclii  tec  ture  is  the  UYK  43  and  the  Mavy  specifies  the  ALS/N  will 
be  used  to  target  to  this  system.  As  such,  one  machine  in  the 
development  environment  must  support  the  ALS/N  (perhaps  a 
MicroVAX).  PCs  (using  PC  compilers)  could  be  used  in  a  networked 
environment  to  increase  productivity  during  the  development  and 
debugging  of  source  code,  but  ultimately  the  machine  hosting  the 
embedded  target  would  be  required  for  the  production  of  target 
code  . 


5.4.  DISTRIBUTED  LIBRARY  SYSTEMS 

A  serious  limitation  associated  with  using  PCs  for  development  is 
the  lack  of  a  distributed  library  system.  A  distributed  library 
allows  team  members  to  compile  parts  of  the  system  on  their 
respective  computers  and  to  then  test  these  elements  without 
having  to  re-compile  on  a  central  computer.  Individual  libraries 
containing  parts  of  the  overall  system  can  therefore  reside  on 
separate  machines  and  the  compilation  overhead  is  more  evenly 
distributed. 

Without  a  distributed  library,  a  central  library  must  be 
maintained  for  integration  and  test.  Completed  source  modules 
mu.'it  be  copied  to  the  central  computer,  and  compiled  into  a 
central  library.  The  benefits  of  using  a  LAN  without  some  type 
of  distributed  library  are  eroded  because  of  the  large  amount  of 


file  transferring  that  mast  take  place. 


5.5.  LOW  LKVRL  FKATURKS 

Ciirrent  compiler  a  lack  many  of  the  low  level  features  which  are 
an  integral  part  of  the  Ada  language.  These  features  are  listed 
in  Chapter  I3  of  the  Reference  Manual  for  the  Ada  Programming 
Language^.  Some  of  the  features  that  are  generally  missing  are: 
support  for  interrupts,  representational  clauses,  and  address 
clauses. 

Lack  of  low  level  features  is  a  major  problem  because  developers 
must  resort  to  using  assembly  language  to  provide  the  machine 
interface.  Sven  though  these  routines  consist  of  only  a  few 
lines  of  code,  they  create  problems  for  ongoing  maintenance  and 
configuration  management.  For  example,  in  SAR'VH,  a  number  of 
small  assembly  routines  are  required  for  functions  such  as  the 
the  low  level  communications  driver  and  keyboard  driver.  This 
has  created  a  problem  for  a  number  of  reasons.  ”irst,  the  .lARAH 
team,  although  well  versed  in  Ada,  does  not  have  very  iiiiich 
experience  with  8088/80286  assembly  language.  Second,  integrating 
the  routines  into  the  software  complicates  ti^e  integration 
process  . 

Each  compiler  vendor  must  provide  an  Appendix  F  to  the  Reference 
Manual  for  the  Ada  Programming  Language  which  must  specify  all 
implementation  dependent  characteristics  of  the  compiler.  The 
Appendix  F  will  indicate  whether  or  not  the  low  level  features 
are  supported. 


6.  EXPERIENCES  AND  PERFORMANCE  ISSUES 


'■'he  experiences  reported  in  th^s  section  relate  mainly  to  the 
Aisys  PC  aT  compiler  ( A  1  ay  CO  i-I  P_003 )  Versions  1.0  and  1.2.  issues 
such  as  code  ePficiency,  the  size  of  the  runtime  support  code, 
and  the  effectiveness  of  the  task  model  implementation  are 
discussed  . 


6.1.  CODE  EFFICIENCY 

The  Aisys  compiler  can  produ  ;e  code  that  is  as  efficient,  if  not 
more  efficient,  as  that  produced  by  the  better  PC  compilers  fc. 
other  languages.  Benchmark  tests'^  compared  the  Aisys  compiler  to 
the  Lattice  C  (Revision  2.15)  compiler  and  Turbo  Pascal  Version 
2.00.  The  results  are  very  encouraging  and  show  thnt  Ada 
compilers  can  in  fact  produce  efficient  code.  In  many  tests  the 
Ada  compiler  outperformed  the  other  compilers.  The  SARAH  team  was 
particularly  interested  to  see  how  well  the  Aisys  compiler 
implemented  procedure  calls.  SARAH  was  designed  using  modern 
software  engineering  practices  and  so  ccn ciots  of  many  small 
functions  and  procedures  (or  tools).  If  the  application  was  to 
operate  effectively,  then  the  overhead  associated  with  procedure 
calls  needed  to  be  minimal.  The  Ackermann  function*^  is  a  good 
indicator  of  how  effectively  calls  are  implemented;  the  benchmark 
tests  showed  that  the  Aisys  implementation  is  considerably  more 
efficient  than  either  Turbo  Pascal  or  Lattice  C. 


6.2.  SIZE  OF  RUNTIME  SUPPORT 

The  runtime  support  module  produced  by  the  Ada  compiler  is  large; 
however,  with  care,  the  size  of  the  runtime  can  be  minimized  for 
a  particular  application.  Experiments  were  done  to  see  how  large 
the  overhead  would  be  when  the  Aisys  compiler  was  used  in 
different  modes  and  when  different  predefined  packages  were  used. 
Compiling  a  simple  procedure  consisting  of  a  single  "null" 
statement  created  an  executable  file  of  15,315  bytes.  If  tasking 
was  added  to  the  runtime,  the  file  size  increased  to  '5  9,953 
bytes.  Compiling  the  same  simple  procedure,  without  tasking,  but 
specifying  protected  (or  extended)  memory  mode  produced  a  file  of 
40,545  bytes.  These  results  show  that  the  overhead  for  tasking 
and  protected  memory  can  be  quite  large,  so  only  those  modes  that 
are  required  should  be  specified. 

In  addition  to  the  runtime  overhead,  use  of  predefined  packages 
can  add  to  the  size  of  executable  files.  For  example,  when  the 
simple  procedure  was  compiled  with  TSXT_I0  (a  package  providing 
standard  text  input/output  routines),  the  executable  file 
increased  in  size  from  15,315  to  41,953  bytes.  If  only  one  or  two 
functions  are  to  Le  used  from  TEXT_I0,  then  this  lo  lar^-  price 
to  pay,  particularly  if  the  target  machine  has  a  constrained 
memory  size.  Since  SARAH  is  to  be  targeted  to  a  Zenith  Z150 
microcomputer  with  only  640  Kilobytes  of  memory,  a  decision  was 


Ml  ,1  .1  not  to  u  a  H  T  1'!  XT  10.  0  t.  Ii  <•  r  p  r  o  li  h  f  i  n  u  (i  ji  n  o  k  a  r  p  a  a  4  d 
(;  o  a  :i  i  li  e  ra  b  1  y  to  t  h  a  a  I  z  e  of  t  h  o  i*  x  i  -  o  u  t  a  b  1  o  f  L  1  u  but  a  o  w  li  a  [■  o  a  o  a  r 
a  3  ra  u  c  li  a  3  X  T _  [  0  .  !>'  o  r  example,  :>  li  Q  II  li  N  1’  L  A  L _  i  0  increased  t  li  e 
3i3e  of  the  executable  file  from  15,313  to  22,177  bytes  while 
OIREC?  10  increases  the  size  to  23,249  bytes. 

If  memory  size  is  constrained  then  care  must  be  taken  to  minimize 
the  runtime  and  pre-defined  package  overhead.  To  see  how  large 
the  overhead  could  become  for  a  typical  application,  the  simple 
"null"  procedure  was  compiled  with  Ti5XT_I0  in  the  tasking  and 
protected  modes.  The  size  of  the  executable  file  was  87,377 
bytes.  That  is  a  big  memory  overhead  just  to  execute  a  "null" 
statement.  By  adding  a  package  which  instantiated  DIRECT_I0  and 
SEQUENTIAL  10,  the  size  of  the  executable  rose  to  94,657  bytes. 
With  Ada,  the  executable  file  can  be  quite  large,  even  if  the 
actual  work  element  is  small.  Care  must  be  taken  to  tailor 
compilation  and  use  of  predefined  packages  to  meet  i,he  need  of 
the  application,  or  an  unnecessary  overhead  will  result. 

6.3.  RENDEZVOUS  TIMES 

Since  rendezvous  times  for  Ada  task  communications  are  still  in 
the  low  millisecond  range,  designers  must  be  careful  not  to  incur 
too  much  of  an  overhead  because  of  task  rendezvous.  Exact 
rendezvous  figures  are  not  available  for  the  Alsys  compiler; 
however,  discussions  with  Alsys  and  other  users  indicate  that 
that  times  are  between  three  and  10  milliseconds.  Until 
rendezvous  times  become  acceptable  (at  least  within  the  raid 
microsecond  range)  designers  should  look  towards  using  procedures 
instead  of  tasks  wherever  possible.  The  Process  Abstraction 
iMethodology  for  Embedded  Large  Applications  (PAMELA)^^  has 
specific  criteria  for  deciding  when  to  use  tasks  and  procedures. 
Several  other  schemes  can  be  used  to  reduce  the  effect  of  poor 
rendezvous  times.  For  example,  the  Modular  Approach  for  Software 
Construction,  Operation  and  Testing  (MASC0T3)^^  uses  control 
queues  and  pools  to  get  around  the  rendezvous  problem. 

6.4.  Task  scheduling 

Currently,  the  Alsys  compiler  does  not  have  timeslicing 
implemented  for  task  sclieduLlng.  As  such,  an  application  which 
has  tasks  may  not  execute  as  ex()ected.  For  example.  Figure  ij.l 
contains  a  simple  tasking  application  where  both  tasks  are  of 
equal  priority.  One  would  think  that  when  the  program  executed, 
we  would  get  a  few  lines  of  "Task  one  active.."  followed  by  a  few 
lines  of  "Task  two  active.."  and  so  on,  depending  on  the  duration 
of  the  time  slice.  What  in  fact  happens  with  the  Alsys  compiler 
is  that  only  one  of  the  messages  will  be  printed  over  and  over 
again.  The  problem  is  that  there  is  no  timeslicing  implemented 
for  task  scheduling  and  so  the  compiler  performs  scheduling  only 
at  task  synch ron i za t i o n  points  (i.e.  at  rendezvous  points,  at  the 
end  of  a  delay,  and  at  task  activation).  As  such,  one  task  will 
execute  until  it  becomes  unrunable,  reaches  a  synchronization 


point,  or  a  task  with  a  higher  priority  benomea  runnble.  Normal 
priority  rules  are  followed  for  pre-empt 'on  and  the  priority 
vf.'tlnes  are  in  the  range  1..10. 

6.5.  QUALITY 

Many  of  the  Ada  products  currently  available  are  of  dubious 
quality;  however,  this  cer-tainly  does  not  apply  to  the  ALSYS 
PC  AT  compiler.  The  Alsys  compiler  is  a  very  reliable  and  robust 
piece  of  software.  Very  few  problems  have  been  iound  with  the 
compiler  and  the  standard  of  documentation  is  extremely  high.  The 
compiler  is  very  easy  to  use  and  comprehensive  on-line  help  is 
available.  The  user  interface  follows  the  conventional  compile, 
bind,  and  execute  cycle  and,  although  easy  to  use,  becomes  a 
little  tedious  after  a  while.  Alsys  should  look  at  provi.  ding  a 
more  integrated  approach  such  as  that  provided  by  Borland  with 
'j’urbo  Pascal.  The  diagnostics  provided  by  tiie  compiler  are 
effective  "'•d  help  pinpoint  many  problems.  In  summary,  the  Alsys 
PC  AT  compiler  is  an  excellent  product. 

This  does  not  mean  that  the  compiler  cannot  be  used  for 
concurrent  applications.  However,  developers  need  to  be 
cognizant  of  this  limitation  so  that  unexpected  problems  do  not 
adversely  affect  the  development  schedule. 


with  T  iilXT_  [  0  ; 
use  T  XT  10; 


procedure  TASK_TK3'r  is  --  a  procedure  to  check  for  task  scheduling 

task  Ta3k_0ne; 
task  Task  Two; 


task  body  Ta3k_0ne  is 
begin 

loop  --forever 

Put_LLne  ("Task  one  active..”); 
end  loop; 

end  Ta3k_0ne; 

task  body  'Task_Two  is 
begin 

loop  --forever 

Put_Line  ("Task  two  active.."); 
end  loop; 

end  Ta3k_Two; 

begin  --activate  tasks 
null; 

end  Task  Tost; 


FIGUEB  6.1  Task  Scheduling  Exauple 
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7.  FUTURE  DIRECTIOBS 


The  micro  compilers  that  are  currently  available  are  aufficient 
for  developing  'id  a  software.  As  illustrated,  there  are  shill 
many  areas  where  improvements  are  required.  This  section 
provides  information  on  the  features  that  will  be  available  in 
future  generations  of  Ada  compilers. 

The  next  generation  of  Ada  compilers  will  provide  1' aster 
compilation.  But  how  fast?  Dr  Robert  Dewar  from  New  York 
University  (NY'J)  indicated  during  a  session  at  the  Pittsburgh 
o  d  A  d  a  meeting  (held  in  .1  u  1  y  1  9  B  6  )  that  NYU  had  d  o  v  e  i  o  p  e  d 
o  f  t  w  a  r  e  for  a  i'  A  I'  which  will  p  e  r  f  o  r  in  .i  y  n  I,  ax  chocks  a  h  a  h  ■)  u  h 
i  1 , 0  0  0  lines  of  Ada  source  code  per  minute.  Prom  this  result 
and  other  research,  he  believes  that  Ada  compilers  should  be  able 
to  compile  at  a  rate  of  20,000  lines  per  minute.  Indeed,  this  is 
big  improvement  over  current  compilers  which  compile,  on  average, 
at  rates  of  less  than  1000  lines  per  minute. 

Vendors  are  now  concentrating  on  code  quality.  Many  of  the 
current  compilers  do  not  support  optimization.  Compiler  vendors 
have  found  that  the  task  of  designing  and  developing  Ada 
compilers  is  enormous.  Now  that  their  compilers  are  operational, 

vendors  are  resorting  to  "fine  tuning".  For  example,  the  next 

version  of  the  Alsys  compiler  will  incorporate  a  high  level 
optimizer.  Plans  are  also  underway  to  introduce  a  low  level 

optimizer.  Code  produced  by  future  Ada  compilers  will  be  far 

more  efficient  than  that  produced  by  current  compilers.  Other 
performance  improvements  will  include  faster  task  rendezvous 
times  and  better  task  scheduling  implementations. 

i’jture  compilers  will  be  more  user-friendly  and  operate  within 
integrated  development  environments.  As  more  Ada  tools  become 
available  for  PCs,  vendors  will  need  to  specify  common  interfaces 
so  that  the  tools  can  work  together.  The  traditional  compile, 
bind  and  execute  cycle  will  give  way  to  a  more  interactive 
environment  which  will  include  syntax  directed  editors,  smart 
debugging  tools,  and  distributed  networks. 

Users  will  ultimately  work  with  a  family  of  compilers.  During 
initial  development,  users  will  be  able  to  eliminate  syntax 
errors  by  using  fast  syntax  parsers  (perhaps  integrated  with  the 
editor}-  To  ensure  the  code  will  compile  correctly,  a  high  speed 
compiler  will  be  used.  This  compiler  will  allow  for  incremental 
and  partial  compilation.  After  the  system  has  been  successfully 
compiled  and  executed,  an  optimizing  compiler  will  produce  the 
efficient  code  needed  for  the  the  final  product.  These  various 
Levels  of  compilation  may  form  an  integral  part  of  in  Ada 
development  environment. 
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8.  SUMMARY  AMD  RBCOMMBNDAT lOHS 


8.1.  SUMMARY 

.  .'I  b  £1 '  t  o  0  1  3  r  e  available  to  il  e  v  e  i  o  p  Ada  o  o  f  t  a  r  .•  w  l  t  h 
microcomputers:  however,  there  is  enormous  room  for  iraprovoment. 
Microcomputers,  particularly  PCs,  are  becoming  more  powerful  and 
so  are  .n  a  better  position  to  effectively  host  Ada  compilers  and 
Ada  1  e  V  e  i.  o  p  ra  e  n  t  tools.  As  the  number  of  Ada  projects  increases, 
ti.  ere  will  be  a  proliferation  of  compilers  and  tools, 
.■■'iicrocomputers  will  play  a  large  part  in  Ada  software 
development.  Networking,  distributed  source  data  bases  and 
libraries,  and  low  costs  will  make  them  attractive  for 
organizations  engaged  in  developing  Ada  software  products. 

d'ritil  recently,  the  Ada  commun’ty  has  lacked  tne  tools  to 
efr.,'cti.vely  develop  Ada  software  applications.  Considering  that 
the  language  was  standardized  in  1983,  vendors  have  been  slow  , 
provide  the  required  compilers  and  tools.  The  complexity  .;f  the 
language,  a  previosly  limited  market,  and  complicated  valid  a ti  on 
procedures  nave  often  been  blamed  for  the  slow  response. 
However,  there  are  now  sufficient  compilers  for  most  applications 
and  the  number  of  new  products  is  increasing  exponentially. 
Armed  with  current  <n<jwledge,  continued  research,  and  ,a  huge  Aia 
Siiftware  market,  compiler  vendors  will  continue  to  improve  their 
products  and  strive  to  provide  features  which  furtiier  aid  tiie  Ada 
3  f  t  w  a  r  e-  developer. 

As  the  number  of  available  Ada  compilers  for  micros  increases, 
effective  requirements  analysis  and  selection  will  be  an 
important  step  in  the  development  process.  Selecting  an  Ada 
compiler  can  he  far  more  difficult  than  selecting  a  compiler  for 
older  languages  because  Ada  compilers  are  more  easily  reii'cted, 
they  possess  features  that  allow  integration  with  other  tools, 
inl  they  are  generally  far  more  complex.  Failure  ti)  correctly 
specify  and  procure  the  right  compiler  could  jeopardize  the 
sur-ess  of  ttie  development  project.  Since  validation  Simply 
ensures  that  the  compiler  conforms  to  the  language  standard,  the 
prospective  users  will  have  to  resort  to  other  techniques  such  as 
benchmarking  to  test  for  quality  and  effectiveness. 

"xperiences  with  the  Alsys  PC  AT  compiler  has  shown  that  Ada  'ode 
can  be  -as  efficient  as  that  produced  by  compilers  for  otiier 
languages.  However,  the  size  of  the  runtime  support  software 
produced  by  the  compiler  will  cause  problems  for  applications 
targeted  to  machines  with  limited  memory  if  compilation  ani  the 
irse  of  predefined  packages  is  not  properly  managed.  Another  area 
of  concern  for  designers  is  task  communications.  Because  of 
inefficient  task  rendezvous,  designers  need  to  carefully  assess 
tank  usage. 


8-2.  RECOMMENDATIONS 


Recommendations  are: 

0  Consideration  should  be  given  to  using  netvrorited  PCs  in 
Ada  development  environments. 

o  Vendor  supplied  pre-deflned  packages  should  be  used  with 
discretion. 

o  Ensure  that  you  are  familiar  with  the  lice  [is  log 

agreements  before  deciding  on  a  compiler. 

o  Perform  an  effective  r  e  u  i  r  e  m  e  n  t  j  a  -i  a  I  y  s  i  s  before 
selecting  a  compiler. 

o  Denchmark  and  test  compilers  before  buying. 

o  When  selecting  a  compiler,  ask  experience  li  users  for 
their  view  of  your  choice. 

0  Ada  software  technology  is  fast  moving  and  so  it  is 

extremely  important  to  keep  abreast  of  developments. 
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wiiich  provides  information  on  Ada  matters. 

Ada  Joint  Program  Office  ( AJPO) ;  A  U.S.  Department  of  Defense 
office  responsible  for  the  Ada  programming  language. 

Ada  Language  System  ( ALS ) ;  An  APSE  developed  by  SofTech  Inc, 
Waltham  MA. 

Ada  Programming  Support  Bnvi ronment  (APSE) :  An  integrated  set  of 
software  development  tools  for  Ada  software  development. 

Ada  Validation  Office  (A  VO):  An  office  of  the  U..S.  Department  of 
Defense  responsible  for  the  validation  of  Ada  compilers. 

Automati_c  Digital  Network  (  AUTODI  M  )  ;  C  om  m  u  n  1  i- a  t  i  o  n  a  network  for 

U.S.  Department  ol‘  Defense. 

Descriptive  Intermediate  Attributed  Notation  for  Ada  (DIANA) :  An 

intermediate  data  representation  for  Ada  compilers. 

Micro:  Short  for  microcomputer.  A  computer  in  which  the  Central 
Processing  Unit  is  made  up  of  one  or  more  microprocessors. 

Millions  o  f  Instructions  Pe  r  Second  ( HIPS) ;  A  measurement  of 
computer  execution  speed. 

Personal  Computer  (PC ) :  A  low  cost  desk-top  microprocessor  based 
computer. 

Personal  Computer-Advanced  Techno  logy  (PC  AT ) ;  A  computer  that 
is  comatible  with  the  I3M  PC  AT.  This  computer  is  based  on  the 
INTEL  80286  microprocessor  and  can  address  up  to  16  Megabytes  of 
memory  in  protected  mode. 

Persona  1  Computer- EX  tended  Techno  1 ogy  (PC  XT) :  A  computer  that 

is  compatible  with  the  IBM  PC  XT.  This  computer  is  based  on  the 
INTEL  8088  microprocessor  and  is  generally  limited  to  640 
Kilobytes  of  phsical  memory. 

Sidekick;  An  on-line  utility  program  from  Borland  that  provides 
features  such  as  a  calendar,  notepad,  calculator,  ASCII  table, 
and  j)  h  o  n  e  directory. 

Standard  Automated  Remote  t  o  AUTO  PI  N  Hjo^t  (SARAH) ;  A  standard 
intelligent  terminal  for  AUTOPIN  users. 

SuperKey ;  An  on-line  utility  program  from  Borland  that  acts  as  a 
i<  o  y  b  o  a  r  d  e  n  oncer. 

:  <•  n  1  t  h  An  lUM  X  I’  o  m  pa  t  i  b  1  e  Ci)'nj>uter  sold  by  I'enith 

!'  (  t  a  Systems. 
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